Data transmission method and apparatus

ABSTRACT

Embodiments of the present invention provide a data transmission method and apparatus. ROHC packets that use a same Context ID are encapsulated into MAC PDU, wherein the MAC PDU is formed by a MAC PDU packet header and a MAC PDU payload. The Context ID of the ROHC packets is carried in the MAC PDU packet header, and the Context ID is not carried in the ROHC packets. The MAC PDU is sent. In this way, transmission resources are saved, and transmission efficiency is improved.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of International Application No.PCT/CN2009/071605, filed on Apr. 30, 2009, which is hereby incorporatedby reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to communications technologies, and inparticular, to a data transmission method and apparatus.

BACKGROUND OF THE INVENTION

Due to the restrictions of physical conditions, compared with a wiredlink, the transmission rate of a wireless link is relatively low, butthe bit error rate is relatively high. When the Internet Protocol (IP)technology is applied in an environment of a wireless network cell, aproblem that a packet header overhead is too large exists. For example,in an IPv6 voice communication packet, a packet payload truly requiredby a user often occupies only 22% of the entire packet, which not onlywastes the bandwidth, but also increases the probability of the packetbeing discarded due to a packet error. If no efficient measure is taken,the wireless network resources are wasted, and meanwhile, the Quality ofService (QoS) is reduced.

By using a header compression mechanism, the forgoing problem may besolved, and at the same time, the inherent flexibility of the IPprotocol may be guaranteed. The header compression mechanisms mayinclude Robust Header Compression (ROHC), Real-time Transport ProtocolHeader Compression (CRTP), and Extended RTP Header Compression (ECRTP).

The ROHC, for example, is a flow-based header compression scheme. Duringnetwork data transmission, most of the header domains of a packet in asame flow have the same values. In the ROHC mechanism, one packet isselected from a certain flow as a reference packet, and for otherpackets, only the information in the header domains that is differentfrom the reference packet is sent, so as to achieve the compressionpurpose, thereby saving the packet header overhead, and utilizing thebandwidth more efficiently. Meanwhile, the ROHC mechanism ensures higheffectiveness and proper robustness by controlling the frequency andquantity of feedback messages, and detecting logic that is notsynchronized, and through error check. Therefore, the ROHC mechanismprovides a header compression mechanism that applies to a link with ahigh bit error rate and a long delay.

The ROHC mechanism has certain universality, and applies to variousnetworks. The packet format defined by the ROHC mechanism requires thateach ROHC packet add a Context ID of the packet and each Initial andRefresh (IR) packet and Initial and refresh-Dynamic (IR-DYN) packet adda Profile ID of the packet.

The inventor finds that, during data transmission, if each ROHC packetcarries a Context ID and/or a Profile ID, data redundancy occurs,thereby wasting network transmission resources.

SUMMARY OF THE INVENTION

Embodiments of the present invention provided a data transmission methodand apparatus, so as to solve the problem of wasting networktransmission resources caused by that each ROHC packet carries a ContextID and/or a Profile ID during data transmission.

An embodiment of the present invention provides a data transmissionmethod, which includes:

-   -   obtaining information about whether a service flow supports        single Context ID, or whether the service flow supports single        Profile, or whether the service flow supports single Context ID        and single Profile; and    -   transmitting Robust Header Compression ROHC packets in the        service flow, wherein: if the service flow supports single        Context ID, the ROHC packets do not carry the Context ID; if the        service flow supports single Profile, the ROHC packets do not        carry the Profile ID of the Profile; if the service flow        supports single Context ID and single Profile, the ROHC packets        do not carry the Context ID and the Profile ID of the Profile.

An embodiment of the present invention provides another datatransmission method, which includes:

-   -   encapsulating ROHC packets that use a same Context ID into Media        Access Control MAC Protocol Data Unit MAC PDU, wherein the MAC        PDU is formed by a MAC PDU packet header and a MAC PDU payload;        the MAC PDU packet header carries the Context ID of the ROHC        packets; and the ROHC packets carried in the MAC PDU payload do        not carry the Context ID; and sending the MAC PDU.

An embodiment of the present invention provides another datatransmission method, which includes:

-   -   encapsulating ROHC packets that use a same Context ID into MAC        PDU, wherein the ROHC packets carried in the MAC PDU do not        carry the Context ID;    -   constructing a downlink scheduling message, wherein the downlink        scheduling message carries the Context ID and the number of the        MAC PDU; and    -   sending the downlink scheduling message and the encapsulated MAC        PDU.

An embodiment of the present invention provides another datatransmission method, which includes:

-   -   receiving, by a Base Station BS, a capability negotiation        request from a Mobile Station MS, wherein the capability        negotiation request carries capability information about whether        the MS supports that a Context ID is carried in a flow        identifier;    -   if the Mobile Station MS supports that the Context ID is carried        in the flow identifier, determining, by the Base Station BS, a        structure of the flow identifier, having the determined flow        identifier structure carried in a capability negotiation        response message, and sending the capability negotiation        response message to the Mobile Station MS; and    -   sending, by the Base Station BS, ROHC packets in a service flow        identified by the flow identifier, or receiving ROHC packets        from the Mobile Station MS in the service flow identified by the        flow identifier, wherein the ROHC packets do not carry a Context        ID.

In the embodiment of the present invention, a CID may be associated withthe Context ID and/or Profile ID, so that the ROHC packet does not carrythe Context ID and/or Profile ID during data transmission. In this way,a waste of transmission resources is reduced, and transmissionefficiency is improved. In addition, ROHC packets with a same Context IDmay be encapsulated into MAC PDU, and the Context ID is carried in thepacket header of the MAC PDU, but does not need to be carried in eachROHC packet. In this way, a waste of transmission resources is reduced,and transmission efficiency is improved.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart of a negotiation between communication partiesaccording to an embodiment of the present invention;

FIG. 2 is a flow chart of a data transmission method according to anembodiment of the present invention;

FIG. 3 is a schematic structure diagram of a MAC PDU formed throughencapsulation in a data transmission method according to an embodimentof the present invention;

FIG. 4 is a flow chart of a data transmission method according to anembodiment of the present invention;

FIG. 5 is a flow chart of a data transmission method according to anembodiment of the present invention;

FIG. 6 is a schematic structure diagram of a data transmission apparatusaccording to an embodiment of the present invention;

FIG. 7 is a schematic structure diagram of a data transmission apparatusaccording to an embodiment of the present invention;

FIG. 8 is a schematic structure diagram of a data transmission apparatusaccording to an embodiment of the present invention; and

FIG. 9 is a schematic structure diagram of a BS according to anembodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In order to make the objectives, technical solutions and advantages ofthe embodiments of the present invention more comprehensible, thetechnical solutions provided in the embodiments of the present inventionare described in details in the following with reference to the specificembodiments and the accompany drawings.

In an embodiment of the present invention, in the scenario where a sameconnection bears single Context ID, the CID (connection identifier) ofthe connection can be associated with the Context ID. In this case, theCID of the connection can serve as the Context ID, and the Context ID inthe ROHC packets can be omitted during data transmission over thisconnection. Or, in the embodiment of the present invention, if, duringestablishment of the service flow corresponding to the connection, thedelivered classification rules merely include relevant information aboutsingle Profile, the CID of the connection may also be associated withthe Profile ID of the single Profile. In this case, the transmitted ROHCpackets do not need to carry the Profile ID. Or, a combination of theabove two cases may occurs, that is, if the connection bears singleContext ID and the classification rules merely include relevantinformation about single Profile, the CID of the connection may beassociated with the Context ID and Profile ID of the single Profile. Inthis case, the Context ID and Profile ID in the ROHC packets may beomitted during data transmission over this connection.

Table 1 shows the format of the ROHC packet after Context ID is deletedin an embodiment of the present invention.

TABLE 1

Table 2 shows the format of the ROHC packet after Profile ID is deletedin an embodiment of the present invention.

TABLE 2

Table 3 shows the format of the ROHC packet after Context ID and ProfileID are deleted in an embodiment of the present invention.

TABLE 3

Preferentially, in the scenario where a same connection bears singleContext ID, both communication parties may negotiate in advance aboutwhether to support single Context or single Profile. As shown in FIG. 1,an embodiment of the present invention further provides a method of anegotiation between communication parties in an embodiment of thepresent invention, which is specifically as follows.

Step 100: An access service network gateway ASN-GW receives anestablishment request message from a connection service network (CSN),and starts to establish an SF (Service flow).

When a service flow needs to be established, the ASN-GW (Access ServiceNetwork Gateway) receives the establishment request message from the CSN(connection service Network) and triggers establishment of an ROHCservice flow. The CSN notifies the ASN-GW in the establishment requestmessage of whether the ROHC service flow supports single Profile, orwhether the ROHC service flow supports single Context ID, or whether theROHC service flow supports single Profile and whether the ROHC serviceflow supports single Context ID.

The establishment request message may be an AAA-REQ (Authentication,Authorization, Accounting request) message, or a RAR (Re-Auth Request)message, where the message may carries an ROHC parameter provided in anembodiment of the present invention. The ROHC parameter carriesinformation about whether the ROHC service flow supports single Profile,whether the ROHC service flow supports single Context ID, or whether theROHC service flow supports single Profile and whether the ROHC serviceflow supports single Context ID. An embodiment of the present inventionprovides two modes to carry the information in the ROHC parameter, whichare as follows.

Mode 1: Adding new fields in the ROHC parameter to carry theinformation, as shown in Table 4.

TABLE 4 ROHC parameter Type 155 Length in octets Variable Value CompoundTLV Description Includes the Per-Channel parameters according RFC3095section 5.1.1 for a single ROHC SF. Elements TLV Name M/O (Sub-TLVs)ROHC_MAX_CID M ROHC_LARGE_CIDS M ROHC_PROFILES M ROHC_FEEDBACK_FOR OROHC_MRRU O ROHC_SUPPORT_ONE_PROFILE O ROHC_SUPPORT_ONE_CONTEXT O ParentTLV SF Info

In Table 4, field ROHC_SUPPORT_ONE_PROFILE and filedROHC_SUPPORT_ONE_CONTEXT are newly added fields in the embodiment of thepresent invention, where the ROHC_SUPPORT_ONE_PROFILE field is used toindicate whether the ROHC service flow supports single Profile, and theROHC_SUPPORT_ONE_CONTEXT field is used to indicate whether the ROHCservice flow supports single Context ID. These two fields are optional.During data transmission, either, both, or neither of the fields can becarried according to actual situations.

Table 5 shows the format of the ROHC_SUPPORT_ONE_PROFILE field.

TABLE 5 Type X + 7 Length in octets 1 Value 0x00 = ROHC ONE PROFILE isnot supported 0x01 = ROHC ONE PROFILE is supported Description ParentTLV ROHC Parameter

In this embodiment, when the value of this field is 0x01, it indicatesthat this ROHC service flow supports single Profile; when the value ofthis field is 0x00, it indicates that this ROHC service flow does notsupport single Profile. Or, in the embodiment of the present invention,when the value of this field is 0x00, it indicates that this ROHCservice flow supports single Profile; when the value of this field is0x01, it indicates that this ROHC service flow does not support singleProfile;

Table 6 shows the format of the ROHC_SUPPORT_ONE_CONTEXT field.

TABLE 6 Type X + 7 Length to octets 1 Value 0x00 = ROHC ONE CONTEXT isnot supported 0x01 = ROHC ONE CONTEXT is supported Description ParentTLV ROHC Parameter

It can be seen from Table 6 that, when the value of this field is 0x01,it indicates that this ROHC service flow supports single Context ID;when the value of this field is 0x00, it indicates that this ROHCservice flow does not support single Context ID. Definitely, in theembodiment of the present invention, when the value of this field is0x00, it indicates that this ROHC service flow supports single ContextID; when the value of this field is 0x01, it indicates that this ROHCservice flow does not support single Context ID;

Mode 2: Endow new meanings to the existing fields, as shown in Table 7.

TABLE 7 Type 155 Length in octets Variable Value Compound TLVDescription Includes the Per-Channel parameters according RFC3095section 5.1.1 for a single ROHC SF. Elements TLV Name M/O (Sub-TLVs)ROHC_MAX_CID M ROHC_LARGE_CIDS M ROHC_PROFILES M ROHC_FEEDBACK_FOR OROHC_MRRU O Parent TLV SF Info

As shown in Table 7, in this embodiment, when the ROHC_LARGE_CIDS fieldis set to a preset value, it indicates that the ROHC service flowsupports single Context ID. For example, it may be that when theROHC_LARGE_CIDS field is set to 0, it indicates that the ROHC serviceflow supports single Context ID. The preset value may be set by theoperator according to the specific requirements. When the ROHC_PROFILESfield is set to a preset value, it indicates whether the service flowsupports single Profile. For example, when the ROHC_PROFILES field isset to a preset value, it indicates that the ROHC service flow carriesthe Profile indicated by the ROHC_PROFILES field;

Step 101: The ASN-GW notifies a BS to establish the service flow.

After receiving the establishment request from the CSN, the ASN-GW sendsa message to the BS to notify the BS to establish a service flow. Themessage may be a Path_Reg_Req message, and the ROHC parameter providedin the forgoing embodiment of the present invention is carried in thismessage, so as to notify the BS that whether the ROHC service flowsupports single Profile, whether the ROHC service flow supports singleContext ID, or whether the ROHC service flow supports single Profile andwhether the ROHC service flow supports single Context ID.

Step 102: The BS requests an MS to establish an air interface connectioncorresponding to the service flow.

In the embodiment of the present invention, the BS sends an airinterface message to the MS, where the air interface message may be aDSA-REQ message, and the ROHC parameter provided in the forgoingembodiment of the present invention is carried in this message, so as tonotify the BS that whether the ROHC service flow supports singleProfile, whether the ROHC service flow supports single Context ID, orwhether the ROHC service flow supports single Profile and whether theROHC service flow supports single Context ID.

Step 103: The MS returns a DSA-RSP message to the BS.

Step 104: The BS returns a Path_Reg_Rsp message to the ASN-GW.

Step 105: The ASN-GW sends a Path_Reg_Ack message to the BS afterreceiving the Path_Reg_Rsp message from the BS.

By far, the establishment of the ROHC service flow is completed, andboth communication parties can transmit data through the ROHC serviceflow.

If it has been negotiated that the ROHC service flow supports singleContext ID during the negotiation, the CID of the connection may beassociated with the Context ID. This CID may serve as the Context ID. Inthis case, the Context ID in the ROHC packets transmitted over thisconnection may be omitted during data transmission.

If it has been negotiated that the ROHC service flow supports singleProfile during the negotiation, and the ROHC service flow merelyincludes information about single Profile, and the CID of the connectionmay be associated with the Profile ID of the single Profile. In thiscase, the Profile ID in the transmitted ROHC packets may be omittedduring data transmission.

If it has been negotiated that the ROHC service flow supports singleContext ID and single Profile during the negotiation, the CID of theconnection may be associated with the Context ID and the Profile ID ofthe single Profile. In this case, the Context ID and Profile ID in thetransmitted ROHC packets may be omitted during data transmission.

In the embodiment of the present invention, if a service flow thatsupports single Profile and/or single Context ID is established, theProfile and/or Context born in this service flow cannot be changed. Ifthe data property is changed during data transmission, for example, ifthe Profile and/or Context of data are changed, the Service FlowManagement (SFM) in the BS may bear the data whose property is changedby establishing a new connection. Optionally, for a dynamic serviceflow, the connection attribute may be directly modified to bear the datawhose property is changed.

Embodiment 2

In the scenario where a same connection may bear multiple Context IDs,ROHC packets with a same Context ID may be arranged and sent in aunified way during scheduling of data transmission. In this way, apublic Context ID may be used to indicate a Context ID of acorresponding ROHC packet, and the Context ID does not need to becarried in each ROHC packet, thereby saving transmission resources andimproving transmission efficiency.

FIG. 2 is a schematic diagram of a data transmission method according toan embodiment of the present invention.

Step 200: Encapsulate data;

After a connection is established, a data sending end encapsulates theROHC packets to be transmitted with a same Context ID into MAC PDU(Media Access Control Protocol Data Unit) at Media Access Control MAClayer, where a MAC PDU is formed by a MAC PDU packet header and a MACPDU payload; the MAC PDU packet header carries the Context ID of theROHC packets; and the ROHC packets carried in the MAC PDU payload do notcarry the Context ID.

Step 201: Transmit data.

The data sending end sends the MAC PDU encapsulated in step 200.

In the embodiment of the present invention, the Context ID of the ROHCpackets is carried in the packet headers of the encapsulated MAC PDUduring MAC layer encapsulation, and the ROHC packets carried in the MACPDU do not need to carry the Context ID. In this way, transmissionresources are saved, and transmission efficiency is improved.

In the embodiment of the present invention, the Context ID of the ROHCpackets may be carried in the packet headers of the encapsulated MAC PDUin several modes as follows.

Mode 1: During data encapsulation, the packet header of a MAC PDU may bedivided into two parts, that is, a public MAC PDU packet header and anindependent MAC PDU packet header. The public MAC PDU packet header isused to carry public information, which may be the Context ID of theROHC packets carried in the MAC PDU, and further includes the CID and/orsecurity parameter of the connection. The independent MAC PDU packetheader includes other relevant information of the MAC PDU, for example,cyclic check and length indication information.

Specifically, the case that 100 ROHC packets are sent over theconnection, where the 100 ROHC packets use two different Context IDs istaken as an example for illustration. It is assumed that 60 ROHC packetsthereof use a first Context ID, and other 40 ROHC packets use a secondContext ID. During data transmission, the data sending end encapsulatethe 60 ROHC packets that use the first Context ID into MAC PDU at theMAC layer. According to the embodiment of the present invention, thepacket header of a first encapsulated MAC PDU may include a public MACPDU packet header and an independent MAC PDU packet header. The publicMAC PDU packet header carries the first Context ID, and may furtherinclude the CID and/or security parameter of the connection. Theindependent MAC PDU packet header includes other relevant information ofthe MAC PDU, for example, cyclic check information. Other MAC PDUencapsulated from the 60 ROHC packets that use the first Context ID maymerely include the independent MAC PDU packet header. Similarly, sameprocessing is performed for other 40 ROHC packets that use the secondContext ID.

Mode 2: In the embodiment of the present invention, a MAC PDU sub packetheader may be added to the end of the MAC PDU packet header during dataencapsulation. The MAC PDU sub packet header includes the Context ID,and all packets behind the MAC PDU sub packet header use a same ContextID. Table 8 shows the format of the MAC PDU sub packet header accordingto an embodiment of the present invention.

TABLE 8 MAC PDU subheader( ){ } type indicates sub packet header typeContext ID context ID

Specifically, the case that 100 ROHC packets are sent over theconnection, where the 100 ROHC packets use two different Context IDs istaken as an example. It is assumed that 60 ROHC packets thereof use afirst Context ID, and other 40 ROHC packets use a second Context ID.During data transmission, the data sending end encapsulate the 60 ROHCpackets that use the first Context ID into MAC PDU at the MAC layer.According to this embodiment of the present invention, a MAC PDU subpacket header is added to the first encapsulated MAC PDU. The MAC PDUsub packet header includes the first Context ID, and all packets behindthe MAC PDU sub packet header use the first Context ID. When other 40ROHC packets are encapsulated, a new MAC PDU sub packet header is addedto the first MAC PDU encapsulated from the 40 ROHC packets. The newlyadded MAC PDU sub packet header includes the second Context ID. As shownin FIG. 3, in this embodiment, for the ROHC packets that use a sameContext ID, only the MAC PDU sub packet header is used to carry theContext ID during MAC layer encapsulation, and the Context ID does notneed to be carried in each ROHC packet. In this way, transmissionresources are saved, and transmission efficiency is improved.

Mode 3: After a connection is established, a data sending endencapsulates the ROHC packets to be transmitted with a same Context IDinto Media Access Control Protocol Data Unit MAC PDU at Media AccessControl MAC layer, where a MAC PDU is formed by a MAC PDU packet headerand a MAC PDU payload. In this embodiment, during data encapsulation,the Context ID does not need to be carried in each ROHC packet. Instead,a field, for example, the Context ID TLV field, is added to the MAC PDUpacket header to carry the Context ID, as shown in Table 9.

TABLE 9 Type TBD Length Variable Value Context Identifier

Preferentially, during data transmission in step 201, for mode 1, tofurther ensure security of data transmission, when sending the MAC PDUencapsulated in step 200, the data sending end may transmit the publicMAC PDU packet header of the MAC PDU in a separate Hybrid AutomaticRepeat Request HARQ channel, and transmit independent MAC PDU packetheader and MSC PDU payload in other HARQ channel. For example, thepublic MAC PDU package header is transmitted in a first HARQ channel,and the independent MAC PDU packet header and MAC PDU payload aretransmitted in a second HARQ channel. Further, for the public MAC PDUpacket header transmitted in the first HARQ channel, a Modulation andCoding Scheme MCS with a higher robustness may be used to performmodulation and coding. In this way, security transmission of theinformation can be further ensured.

For mode 2, to further ensure security of data transmission, whensending the MAC PDU encapsulated in step 200, the data sending end maytransmit the MAC PDU sub packet header of the MAC PDU in a separate HARQchannel, and transmit the independent MAC PDU packet header and MAC PDUpayload in other HARQ channel. For example, the MAC PDU sub packetheader of the MAC PDU is transmitted in a first HARQ channel, and theindependent MAC PDU packet header and MAC PDU payload is transmitted ina second HARQ channel. Further, for the MAC PDU sub packet headertransmitted in the first HARQ channel, a Modulation and Coding SchemeMCS with a higher robustness may further be used to perform modulationand coding. In this way, security transmission of this information maybe further ensured.

The data transmission method provided in the embodiment of the presentinvention is applicable to uplink transmission and downlinktransmission. That is, the data sending end may be a BS or an MS.Accordingly, the data receiving end may be an MS or a BS.

As shown in FIG. 4, an embodiment of the present invention furtherprovides a data transmission method. During downlink data transmission,a BS schedules ROHC packets with a same Context ID for MAC layerencapsulation to form MAC PDU. During encapsulation, the ROHC packets donot need to carry the Context ID. The BS notifies an MS of the relevantContext ID information through other message, which are specifically asfollows.

Step 400: Encapsulate data.

After a connection is established, the BS encapsulates ROHC packets witha same Context ID into Media Access Control Protocol Data Unit MAC PDUat Media Access Control MAC layer. In the embodiment of the presentinvention, during data encapsulation, the Context ID does not need to becarried in each ROHC packet.

Step 401: Notify the MS of the Context ID and the number of related MACPDU, and send data.

In the embodiment of the present invention, for the MAC PDU with a sameContext ID encapsulated in Step 400, the BS notifies the MS of theContext ID and the number of related MAC PDU through a downlinkscheduling message. For example, the information may be sent to the MSthrough a DL_MAP message. The BS sends the encapsulated MAC PDU to theMS. In this embodiment, the MAC PDU and the DL_MAP message may becarried in a same frame, and sent to the MS. The MS parses the MAC PDUfrom the BS according to the Context ID and the number of related MACPDU obtained through parsing of the downlink scheduling message toobtain the ROHC packets and the corresponding Context ID used by theROHC packets.

In this embodiment, the ROHC packets that use a same Context ID notifythe MS of the Context ID and the number of related MAC PDU through adownlink scheduling message, and the ROHC packets encapsulated into theMAC PDU do not need to carry the Context ID. In this way, transmissionresources are saved, and transmission efficiency is improved.

Embodiment 3

In the scenario where a flow identifier is used to identify a serviceflow, in the embodiment of the present invention, the flow identifiercan indicate the Context ID. In this way, the ROHC packets transmittedin this service flow do not need to carry the Context ID. In theembodiment of the present invention, the structure of the flowidentifier may be flexibly designed, so that several bits in thestructure may be used to indicate the Context ID. Or, the structure ofthe flow identifier may be obtained through negotiation between the MSand the BS in advance, as shown in FIG. 5, which is specifically asfollows.

Step 500: The BS receives a capability negotiation request from the MS.

In the embodiment of the present invention, in the capabilitynegotiation process during accessing the network, the MS may negotiatewith the BS about the structure of the flow identifier. For example, itmay be that the BS receives a capability negotiation request from theMS, where the capability negotiation request carries capabilityinformation about whether the MS supports that a Context ID is carriedin the flow identifier. For example, the capability negotiation requestmay be an SBC_REQ message, and it may be that a new field is added tothe message to carry information about whether the MS supports that aContext ID is identified in the flow identifier. The field is as shownin Table 10.

TABLE 10 Type TBD Length in octets 1 Value 0 or 1

As shown in Table 10, if the value of the field value is 0, it indicatesthat the MS does not support that the Context ID information isidentified in the flow identifier; if the value of this field is 1, itindicates that the MS supports that the Context ID information isidentified in the flow identifier;

Step 501: The BS returns a capability negotiation response to the MS.

After receiving the capability negotiation request, for example, anSBC_REQ message, from the MS, the BS returns a capability negotiationresponse, for example, an SBC_RSP message, to the MS. In thisembodiment, if the capability negotiation request sent by the MSindicates that the MS does not support that the a Context ID isidentified in the flow identifier, the conventional technology can beused for processing; if the capability negotiation request sent by theMS indicates that the MS supports that a Context ID is carried in theflow identifier, the flow identifier structure field may be added to thecapability negotiation response message, and the structure of the flowidentifier determined by the BS is sent through this field to the MS.Table 11 shows the structure of the flow identifier structure field.

TABLE 11 Type TBD Length in octets 2 Value

As shown in Table 11, a structure of the flow identifier is described inthe flow identifier structure field. The flow identifier includes 2bytes (i.e.16 bits). The value of each bit is 0 or 1, respectivelyindicating that the bit indicates flow information or Context IDinformation. When Bit=1, it indicates that this bit is used to identifythe flow information; when Bit=0, it indicates that this bit is used toidentify the Context ID information. Definitely, it may also be thatBit=0, it indicates that this bit is used to identify the flowinformation; and Bit=1, it indicates that this bit is used to identifythe Context ID information.

Step 502: Transmit data.

After capability negotiation is completed, the BS and MS may performdata transmission. During transmission, since the Context ID informationis informed in the flow identifier that identifies the service flow, theROHC packets transmitted in this service flow do not need to carry theContext ID again. In this way, transmission resources are saved, andtransmission efficiency is improved.

In the method provided in the embodiment of the present invention, afterthe MS and the BS negotiate the structure of the flow identifier, theContext ID of the ROHC packets may be omitted during uplink or downlinkdata transmission.

An embodiment of the present invention further provides a datatransmission apparatus. FIG. 6 shows the apparatus provided in theembodiment of the present invention. The apparatus includes an obtainingmodule 600 and a transmitting module 602, where the obtaining module 600is configured to obtain information about whether a service flowsupports single Context ID, whether the service flow supports singleProfile, or whether the service flow supports single Context ID andsingle Profile; and the transmitting module 602 is configured totransmit Robust Header Compression ROHC packets over the service flow.If the service flow supports single Context ID, the ROHC packets do notcarry the Context ID; if the service flow supports single Profile, theROHC packets do not carry the Profile ID of the Profile; and, if theservice flow supports single Context ID and single Profile, the ROHCpackets do not carry the Context ID and the Profile ID of the Profile.In this embodiment, the data transmission apparatus may be an accessservice network gateway ASN-GW. After the data transmission apparatusobtains related information, the ROHC packets transmitted over theservice flow do not need to carry the Context ID and/or Profile IDagain. In this way, transmission resources are saved, and transmissionefficiency is improved.

An embodiment of the present invention further provides a datatransmission apparatus. FIG. 7 shows the data transmission apparatusprovided in this embodiment, where the apparatus includes:

-   -   an encapsulating module 700, configured to: encapsulate ROHC        packets with a same Context ID into MAC PDU, where: a MAC PDU is        formed by a MAC PDU packet header and a MAC PDU payload; the MAC        PDU packet header carries the Context ID of the ROHC packets;        and the ROHC packets carried in the MAC PDU payload do not carry        the Context ID; and a sending module 702, configured to send the        MAC PDU.

According to the apparatus provided in this embodiment of the presentinvention, during MAC PDU encapsulation, the Context ID of the ROHCpackets is encapsulated in the packet header of the MAC PDU, and theROHC packets carried in the MAC PDU do not need to carry the Context ID.In this way, transmission resources are saved, and transmissionefficiency is improved.

Further, the encapsulating module 700 specifically includes: a MAC PDUpacket header encapsulating module and a MAC PDU payload encapsulatingmodule.

The MAC PDU packet header encapsulating module is configured toencapsulate a public MAC PDU packet header and an independent MAC PDUpacket header for a first MAC PDU when encapsulating the first MAC PDU,where the public MAC PDU packet header carries the Context ID, and theindependent MAC PDU packet header carries the information of the MACPDU, for example, cyclic check and length indication information. TheMAC PDU packet header encapsulating module is configured to encapsulateindependent MAC PDU packet header for other MAC PDU, where the publicMAC PDU packet header may further carry the CID of the connection and/orsecurity parameters.

Or, the MAC PDU packet header encapsulating module is configured toencapsulate a MAC PDU packet header and a MAC PDU sub packet header fora first MAC PDU when encapsulating the first MAC PDU, where: the MAC PDUsub packet header carries the Context ID and encapsulate the MAC PDUpacket header for other MAC PDU; the format of the MAC PDU sub packetmay be the format shown in the above Table 8; and the MAC PDU packetheader includes related information about the MAC PDU, for example,cyclic check and length indication information.

Or, the MAC PDU packet header encapsulating module is configured toencapsulate a MAC PDU packet header for a MAC PDU, where the MAC PDUpacket header carries the Context ID, for example, a field, such asContext ID TLV field, may be added to the MAC PDU packet header to carrythe Context ID, as shown in Table 9.

The MAC PDU payload encapsulating module is configured to encapsulate aMAC PDU payload for MAC PDU, that is, the ROHC packets used as thepayload is encapsulated into the MAC PDU payload, where each ROHC packetencapsulated in the MAC PDU payload does not need to carry the ContextID.

Preferentially, the sending module 702 may further include a firstsending sub module and a second sending sub module, where: the firstsending sub module may be configured to send the public MAC PDU packetheader in a first hybrid automatic repeat request channel; the secondsending sub module may be configured to send the independent MAC PDUpacket header and MAC PDU payload in a second hybrid automatic repeatrequest channel; or the first sending sub module may be configured tosend the MAC PDU sub packet header in the first hybrid automatic repeatrequest channel; and the second sending sub module may be configured tosend the MAC PDU packet header and MAC PDU payload in the second hybridautomatic repeat request channel.

Preferentially, the sending module 702 can further include a modulatingand encoding module, where the module is configured to use theModulation and Coding Scheme MCS with a high robustness to modulate andencode the public MAC PDU packet header or MAC PDU sub packet header;the first sending sub module is configured to send the public MAC PDUpacket header or MAC PDU sub packet header after modulation and encodingin the first hybrid automatic repeat request channel.

In this embodiment of the present invention, the data transmissionapparatus may be a Base Station BS or a Mobile Station MS.

An embodiment of the present invention further provides a datatransmission apparatus. As shown in FIG. 8, the apparatus includes anencapsulating module 800, a constructing module 802, and a sendingmodule 804. The encapsulating module 800 is configured to encapsulateROHC packets that use a same Context ID into MAC PDU, where the ROHCpackets carried in the MAC PDU do not carry the Context ID. Theconstructing module 802 is configured to construct a downlink schedulingmessage, where the downlink scheduling message carries the Context IDand the number of MAC PDU encapsulated by the encapsulating module 800.The sending module 804 is configured to send the downlink schedulingmessage and encapsulated MAC PDU. The downlink scheduling message heremay be a DL_MAP message. The sending module may have the MAC PDU and theDL_MAP message carried in a same frame and send the frame to the MS. Inthis case, the MS parses the MAC PDU from the BS according to theContext ID and the number of related MAC PDU obtained through parsing ofthe downlink scheduling message to obtain the ROHC packets and thecorresponding Context ID used by the ROHC packets.

According to the data sending apparatus, the ROHC packets that use asame Context ID may notify the MS of the Context ID and the number ofrelated MAC PDU through a downlink scheduling message, and the ROHCpackets encapsulated into the MAC PDU do not need to carry the ContextID. In this way, transmission resources are saved, and transmissionefficiency is improved.

An embodiment of the present invention further provides a base station.As shown in FIG. 9, the base station includes a receiving module 900, afeedback module 902, and a transmitting module 904. The receiving module900 is configured to receive a capability negotiation request from aMobile Station MS, where the capability negotiation request carriescapability information about whether the Mobile Station MS supports thata Context ID is carried in a flow identifier. In the embodiment of thepresent invention, in capability negotiation process during accessingthe network, the Mobile Station MS may negotiate with the BS about astructure of the flow identifier. The capability negotiation request maybe an SBC_REQ message, and it may be that a new field is added to themessage to carry information about whether the MS support that ContextID information is identified in the flow identifier. The field is asshown in Table 10. The feedback module 902 is configured to, if theMobile Station MS supports that the Context ID is carried in the flowidentifier, determine the structure of the flow identifier, have thedetermined structure of the flow identifier carried in a capabilitynegotiation response message, and send the capability negotiationresponse message to the Mobile Station MS. The capability negotiationresponse message may be an SBC_RSP message, and it may be that a flowidentifier structure field is added to the capability negotiationresponse message. The flow identifier structure determined by the BaseStation BS is sent to the Mobile Station MS through this field. Table 11shows the structure of the flow identifier structure field provided inthis embodiment of the present invention. The transmitting module 904 isconfigured to send ROHC packets in a service flow identified by the flowidentifier to the mobile station, or receive ROHC packets from themobile station in the service flow identified by the flow identifier,where the ROHC packets do not carry a Context ID.

In this way, after the base station according to an embodiment of thepresent invention negotiates with the mobile station about the structureof the flow identifier, the Context ID in the ROHC packets may beomitted during uplink or downlink data transmission. In this way,transmission resources are saved, and transmission efficiency isimproved.

Persons of ordinary skill in the art may understand that all or a partof the steps in the method according to the embodiments of the presentinvention may be implemented by a program instructing relevant hardware,and the program may be stored in a computer readable storage medium.When the program is run, the steps are as follows: encapsulating ROHCpackets that use a same Context ID into Media Access Control MACProtocol Data Units MAC PDU, where: the MAC PDU is formed by a MAC PDUpacket header and a MAC PDU payload; the MAC PDU packet header carriesthe Context ID of the ROHC packets; and the ROHC packets carried in theMAC PDU payload do not carry the Context ID; and sending the MAC PDU.

The storage medium mentioned above may be a read-only memory, a magneticdisk, or an optical disk.

To sum up, the above descriptions are merely the exemplary embodimentsof the present invention, but the protection scope of the presentinvention is not limited thereto. Any modification or replacement thatcan be easily figured out by persons skilled in the art within thetechnical scope disclosed by the present invention shall fall within theprotection scope of the present invention. Therefore, the protectionscope of the present invention shall be subject to the appended claims.

1. A data transmission method, comprising: obtaining information about whether a service flow supports single Context ID, or whether the service flow supports single Profile, or whether the service flow supports single Context ID and single Profile; and transmitting Robust Header Compression ROHC packets in the service flow, wherein: if the service flow supports single Context ID, the ROHC packets do not carry the Context ID; if the service flow supports single Profile, the ROHC packets do not carry the Profile ID of the Profile; if the service flow supports single Context ID and single Profile, the ROHC packets do not carry the Context ID and the Profile ID of the Profile.
 2. The method according to claim 1, wherein the obtaining information about whether a service flow supports single Context ID, or whether the service flow supports single Profile, or whether the service flow supports single Context ID and single Profile specifically comprises: receiving, by an Access Service Network Gateway ASN-GW, an establishment request message from a Connection Service Network CSN, wherein: the establishment request message carries an ROHC parameter; the ROHC parameter comprises information about whether the service flow supports single Context ID, or whether the service flow supports single Profile, or whether the service flow supports single Context ID and single Profile; sending, by the ASN-GW, a message to a Base Station BS, wherein the message carries the ROHC parameter; sending, by the BS, an air interface message to a Mobile Station MS to request for establishing an air interface connection corresponding to the service flow; wherein the air interface message carries the ROHC parameter; receiving, by the BS an air interface acknowledgement message from the MS, returning, by the BS, an acknowledgement message to the ASN-GW; and sending, by the ASN-GW, a response message to the BS.
 3. The method according to claim 2, wherein the ROHC parameter carries the information about whether the service flow supports single Context ID, or whether the service flow supports single Profile, or whether the service flow supports single Context ID and single Profile comprises: adding a new ROHC_SUPPORT_ONE_PROFILE field to the ROHC parameter to indicate whether the service flow supports single Profile; and/or adding a new ROHC_SUPPORT_ONE_CONTEXT field to the ROHC parameter to indicate whether the service flow supports single Context ID.
 4. The method according to claim 2, wherein the ROHC parameter carries the information about whether the service flow supports single Context ID, or whether the service flow supports single Profile, or whether the service flow supports single Context ID and single Profile comprises: setting a preset value of an ROHC_LARGE_CIDS field in the ROHC parameter to indicate whether the service flow supports single Context ID; and/or setting a preset value of an ROHC_PROFILES field to indicate whether the service flow supports single Profile.
 5. A data transmission method, comprising: encapsulating ROHC packets that use a same Context ID into Media Access Control MAC Protocol Data Unit MAC PDU, wherein the MAC PDU is formed by a MAC PDU packet header and a MAC PDU payload, the MAC PDU packet header carries the Context ID of the ROHC packets, and the ROHC packets carried in the MAC PDU payload do not carry the Context ID; and sending the MAC PDU.
 6. The method according to claim 5, wherein the MAC PDU packet header carries the Context ID of the ROHC packets comprises: dividing a MAC PDU packet header of a first encapsulated MAC PDU into a public MAC PDU packet header and an independent MAC PDU packet header, wherein the public MAC PDU packet header carries the Context ID, and the independent MAC PDU packet header carries information about the MAC PDU.
 7. The method according to claim 5, wherein the MAC PDU packet header carries the Context ID of the ROHC packets comprises: adding a MAC PDU sub packet header to the end of the MAC PDU packet header of the first encapsulated MAC PDU, wherein the MAC PDU sub packet header carries the Context ID.
 8. The method according to claim 5, wherein the MAC PDU packet header carries the Context ID of the ROHC packets comprises: adding a new field to the MAC PDU packet header of the encapsulated MAC PDU, wherein the new field carries the Context ID.
 9. The method according to claim 5, further comprising: constructing a downlink scheduling message, wherein the downlink scheduling message carries the Context ID and the number of the MAC PDU; and sending the downlink scheduling message.
 10. The method according to claim 6, wherein the public MAC PDU packet header further carries a connection identifier CID and/or a security parameter.
 11. The method according to claim 6, wherein the sending the MAC PDU comprises: sending the public MAC PDU packet header in a first hybrid automatic repeat request channel; and sending the independent MAC PDU packet header and the MAC PDU payload in a second hybrid automatic repeat request channel.
 12. The method according to claim 7, wherein the sending the MAC PDU comprises: sending the MAC PDU sub packet header in a first hybrid automatic repeat request channel; and sending the MAC PDU packet header and the MAC PDU payload in a second hybrid automatic repeat request channel.
 13. The method according to claim 11, wherein before sending the public MAC PDU packet header in the first hybrid automatic repeat request channel the method further comprises: using a Modulation and Coding Scheme MCS with a high robustness to modulate and encode the public MAC PDU packet header; and the sending the public MAC PDU packet header in a first hybrid automatic repeat request channel comprises: sending the public MAC PDU packet header after modulation and encoding in the first hybrid automatic repeat request channel.
 14. The method according to claim 12, wherein before the sending the MAC PDU sub packet header in the first hybrid automatic repeat request channel the method further comprises: using a Modulation and Coding Scheme MCS with a high robustness to modulate and encode the MAC PDU sub packet header; and the sending the MAC PDU sub packet header in a first hybrid automatic repeat request channel comprises: sending the MAC PDU sub packet header after modulation and encoding in the first hybrid automatic repeat request channel.
 15. A data transmission apparatus, wherein the apparatus comprises: an obtaining module, configured to obtain information about whether a service flow supports single Context ID, or whether the service flow supports single Profile, or whether the service flow supports single Context ID and single Profile; and a transmitting module, configured to transmit Robust Header Compression ROHC packets in the service flow, wherein if the service flow supports single Context ID, the ROHC packets do not carry the Context ID; if the service flow supports single Profile, the ROHC packets do not carry the Profile ID of the Profile; if the service flow supports single Context ID and single Profile, the ROHC packets do not carry the Context ID and the Profile ID of the Profile.
 16. A data transmission apparatus, wherein the apparatus comprises: an encapsulating module, configured to encapsulate ROHC packets that use a same Context ID into MAC PDU, wherein the MAC PDU is formed by a MAC PDU packet header and a MAC PDU payload; the MAC PDU packet header carries the Context ID of the ROHC packets; and the ROHC packets carried in the MAC PDU payload do not carry the Context ID; and a sending module, configured to send the MAC PDU encapsulated by the encapsulating module.
 17. The apparatus according to claim 16, wherein the encapsulating module comprises: a MAC PDU packet header encapsulating module, configured to encapsulate a public MAC PDU packet header and an independent MAC PDU packet header for a first MAC PDU, wherein the public MAC PDU packet header carries the Context ID and the independent MAC PDU packet header carries the information about the MAC PDU, and encapsulate the independent MAC PDU packet header for other MAC PDU; and a MAC PDU payload encapsulating module, configured to encapsulate MAC PDU payload for the MAC PDU.
 18. The apparatus according to claim 16, wherein the encapsulating module comprises: a MAC PDU packet header encapsulating module, configured to encapsulate a MAC PDU packet header and a MAC PDU sub packet header for the first MAC PDU, wherein the MAC PDU sub packet header carries the Context ID, and encapsulate the MAC PDU packet header for other MAC PDU; and a MAC PDU payload encapsulating module, configured to encapsulate MAC PDU payload for the MAC PDU.
 19. The apparatus according to claim 16, wherein the encapsulating module comprises: a MAC PDU packet header encapsulating module, configured to encapsulate the MAC PDU packet header for the MAC PDU, wherein the MAC PDU packet header carries the Context ID; and a MAC PDU payload encapsulating module, configured to encapsulate MAC PDU payload for the MAC PDU.
 20. The apparatus according to claim 16, further comprising: a constructing module, configured to construct a downlink scheduling message, wherein the downlink scheduling message carries the Context ID and the number of the MAC PDU encapsulate by the encapsulating module; and wherein the sending module is further configured to send the downlink scheduling message.
 21. The apparatus according to claim 17, wherein the sending module comprises: a first sending sub module, configured to send the public MAC PDU packet header in the first hybrid automatic repeat request channel, and a second sending sub module, configured to send the independent MAC PDU packet header and the MAC PDU payload in the second hybrid automatic repeat request channel.
 22. The apparatus according to claim 18, wherein the sending module comprises: a first sending sub module, configured to send the MAC PDU sub packet header in the first hybrid automatic repeat request channel, and a second sending sub module, configured to send the MAC PDU packet header and the MAC PDU payload in the second hybrid automatic repeat request channel.
 23. The apparatus according to claim 21, wherein the sending module further comprises: a modulating and encoding module, configured to use a Modulation and Coding Scheme MCS with a high robustness to modulate and encode the public MAC PDU packet header; and wherein the first sending sub module is configured to send the public MAC PDU packet header after modulation and encoding in the first hybrid automatic repeat request channel.
 24. The apparatus according to claim 22, wherein the sending module further comprises: a modulating and encoding module, configured to use a Modulation and Coding Scheme MCS with a high robustness to modulate and encode the MAC PDU sub packet header; and wherein the first sending sub module is configured to send the MAC PDU sub packet header after modulation and encoding in the first hybrid automatic repeat request channel.
 25. A base station, wherein the base station comprises: a receiving module, configured to receive a capability negotiation request from a Mobile Station MS, wherein the capability negotiation request carries capability information about whether the Mobile Station MS supports that a Context ID is carried in a flow identifier; a feedback module, configured to: if the MS supports that the Context ID is carried in the flow identifier, determine a structure of the flow identifier, have the determined flow identifier structure carried in a capability negotiation response message, and send the capability negotiation response message to the MS; and a transmitting module, configured to send ROHC packets in a service flow identified by the flow identifier to the MS, or receive ROHC packets from the MS in the service flow identified by the flow identifier, wherein the ROHC packets do not carry a Context ID. 